1. Field of the Invention
Embodiments of the invention generally relate to database management and, in particular, to methods, executable instructions and associated computer-readable media, for alleviating failure associated with replication of a large database or a database wherein the data source exceeds a transaction capacity of the database.
2. Description of Related Art
A database (DB) is a computerized information storage and retrieval system. A Relational Database Management System (RDBMS) is a database management system that uses relational techniques for storing and retrieving data. An example of a well known RDBMS is the DB2 family of systems manufactured by IBM. RDBMS software using a Structured Query Language (SQL) interface is also well known in the art. The SQL interface has evolved into a standard language for RDBMS software and has been adopted as such by both the American National Standards Organization (ANSI) and the International Standards Organization (ISO). For further information the interested reader is directed to U.S. Pat. No. 6,622,152, which is hereby incorporated by reference in its entirety to the fullest extent allowed by applicable laws and rules. The interested reader is further directed to the Internet address https://aurora.vcu.edu/db2help/db2a0/form3toc.htm, which presents a detailed Application Development Guide that discusses how to design and code application programs that access DB2 databases, incorporated herein by reference in its entirety.
The DB2 Universal DataBase-Data Propagation/Replication (DB2 UDB dPropR) system provides an application that allows the replication of data from DB2 source databases to DB2 target databases. This application also can be used to replicate data between DB2 and non-IBM source and target databases. The replication of large data loads, e.g., single database tables of about 10 GB or greater, or a database table that exceeds a transaction capacity of the database, can be problematic. This is especially the case at initial start-up, or when refreshing a target table. These operations are referred to herein as a “cold start” operation (i.e., involving the transfer of all data in the database table). In contrast, a “warm start,” or a continue-mode transfer operation, refers to data transfer that continues from an identified stop point or synchronization marker, as those terms are understood in the art. Large database replication requires correspondingly large amounts of free (memory) space. For a successful cold start transfer, a target database requires sufficient free tablespace to receive all of the data, plus enough free logspace and enough free tempspace to hold two complete copies of the target database table. Thus the total “free space” required is approximately three times that of the largest anticipated table.
Another challenge relates to the “all or nothing” characteristic of a cold start. A drawback of a cold-start is that either all of the data successfully loads from the source to the target, or the process fails, typically due to a full transaction log. This occurs because the amount of data in the single transfer far exceeds the capacity of the receiving transaction space. In failure mode, the database manager will rollback the table to its original state. As such, the data is never propagated to the target/destination.
Another recognized problem pertains to time lost due to failure of the replication operation. It is often difficult to accurately predict how much free space a large data transfer operation will require. A short estimate may result in the replication operation running for several hours or longer. In failure mode, the process will error-out and run again for several hours in an attempt to recover. This cycle of attempting to replicate and failing may continue indefinitely, resulting in obvious losses.
Furthermore, the database itself may have problems. For example, during the loading of a database all tables sharing the same tablespace are unavailable until the load is completed. Thus the database residing on the target database server may be come unavailable for an extended period of time. Moreover, if the load fails, the tablespace could be left in a ‘load-pending’ state, jeopardizing the entire database. The loading of large amounts of data also may require temporary customization of the database, which may in turn require that the database or database engine be recycled.
In light of the foregoing recited drawbacks and disadvantages, and others that are appreciated by those skilled in the art, the inventors have recognized the need for a solution that addresses these problems in a consistent, successful manner and with minimal interactions and drawbacks. A solution is embodied by the invention set forth herein.